1. Field of the Invention
The present invention generally relates to the field of data processing and to computerized systems and methods that implement formulas. More particularly, the invention relates to systems and methods that assist users in building and implementing formulas for data processing and other applications.
2. Background Information
Many current computer software applications, such as spreadsheets and database managers, accept and use formulas. Generally, a formula is a mathematical construct that defines a relationship between two or more values contained in the formula's operands.
As a specific example of an application that uses formulas, consider a spreadsheet application. A typical spreadsheet is a computerized matrix of rows and columns defining cells. A spreadsheet resembles an accountant's worksheet and is used for tasks such as budgeting, check balancing, calculations for decision charts, grading calculations, and what-if computations, among others. Spreadsheet rows are typically labeled with numbers (1,2,3,4, . . . ) and columns are typically labeled with letters (A, B, C, D, . . . ). A cell is identified by its column and row names, such as “C2.”
A spreadsheet cell may contain different things, including a label, a value, a formula, or a function. A label is typically descriptive text. Labels cannot be treated mathematically; that is, they cannot be multiplied, subtracted, etc. A typical spreadsheet application program may treat any cell contents beginning with A-Z (e.g., ALIMONY, TOTAL, HOUSEHOLD EXPENSES, etc.) as a label. Values are numbers that are the data in a spreadsheet (e.g., 5, 123.45, 999.5, etc.). The spreadsheet can treat values mathematically. For example, with a spreadsheet, values can be multiplied, subtracted, squared, etc. Formulas defined in a spreadsheet may perform mathematical calculations on a set of operands, such as referenced cells and constants (e.g., A1+C2+A3, A1+A2/3 , etc.). The calculation is determined by the operator(s) in the formula, which may be mathematical operators (+, −, *, /, etc.) or comparison operators (=, <, >, etc.), among others.
Many spreadsheets require formulas to begin with an equal sign “=,” so the application recognizes the cell contents as a formula (e.g., =A1+C2+A3 and =A1+A2/3). The spreadsheet performs the mathematical operations on the referenced cells and constants.
The spreadsheet user (or calling program) defines a formula using a formula builder component of the application with an interface that allows the user to enter and edit a formula. In Microsoft Excel™ for example, the formula builder interface is a bar located below the toolbar. If the formula is not entered correctly, it may produce an erroneous result or be flagged as an error by the spreadsheet application. Similarly, if the referenced cells contain erroneous data, the formula's output will be incorrect.
A predefined set of formulas or functions may be built into the spreadsheet program. Common functions are available, such as: “SUM” which totals the values in the cells referenced; “AVERAGE” which finds the average of the values in the cells referenced; and “STDEV” which finds the standard deviation of the values in the cells referenced.
Typically, functions begin with an equals sign “=” followed by the function name and the referenced cells on which the function is performed. For example, =SUM(A1:A3) adds the values in the referenced cells A1+A2+A3 and places the answer in the cell containing the function. As with formulas, the spreadsheet user or calling program enters the function's referenced cells. If the referenced cells contain erroneous data, the function's output will be incorrect.
Errors in the result output by a formula or function can be costly, especially in applications used in business. For example, if formulas are used to compute the key operating figures for a company, errors in the formula output can generate misleading results or incorrect performance indicators. Many errors are caused by manual user input mistakes or variations in the data source(s), yet, business application customers must have a formula builder to define and implement formulas, which are often used to calculate key figures that are unique to each business. This is especially true for analytical applications, such as spreadsheets and database managers, because the formulas used tend to be highly user-specific and thus unsuited for canned predefinition in the application code by a software vendor.
Conventional formula builders, however, have several shortcomings that make the task of defining and implementing formulas complex and error prone. For instance, many of the values used in a typical business formula calculation have an associated dimension, such as a value that stands for an amount of money or a quantities of products, as opposed to being a dimensionless scalar. Conventional formula builders, however, (such as the one in the Microsoft Excel™ spreadsheet program) treat all values as scalars. This creates a problem if the formula performs an operation on nonscalar values having dimensions that don't match, such as adding an amount of money value to a quantity of widgets value. Similarly, treating all values as scalars creates a problem if the formula performs an operation on values that have the same dimension but different units, such as adding a quantity in pounds to a quantity in kilograms, or adding an amount in dollars to an amount in Euros.
Because of this treatment, the user of a conventional formula builder must check whether dimensions and/or units are consistent and correct, and if not, painstakingly create a formula that explicitly performs conversions and treats dimensions correctly.
Because they handle all values as scalars, conventional formula builders cannot detect errors caused by performing operations on operands having incompatible dimensions. For example, a conventional spreadsheet does not check whether a user-defined formula is erroneously trying to add a quantity-dimensioned operand (such as 100 pieces) to a price-dimensioned operand (such as 100 Euros per 100 pieces) or erroneously trying to multiply two quanties (such as 100 pieces×50 pieces) instead of correctly multiplying a quantity by a scalar (100 pieces×50). Similarly, a conventional spreadsheet does not check whether a user-defined formula is erroneously trying to perform operations on two operands that are expressed in different units, such as adding a quantity expressed in units of pounds to a quantity expressed in units of kilograms. Not taking an operand's dimension and units into account causes errors and results in inefficient troubleshooting and correction of formulas.
For example, a business's production costs of materials are calculated by adding up the costs of all materials and activities required to produce its product. A basic formula for this to be entered in an application may be: Production Costs=Σ(Costs of Raw Materials)+Σ(Costs of Activities). A problem arises with this formula, however, if the values for the costs of raw materials and the values for the costs of activities are stored in the application in different currencies, as might be the case if materials are imported from one country to produce a product in another country. A conventional formula builder requires the user to explicitly enter currency unit conversions so that the formula calculates the correct results. Consider, for example, a conventional application program that includes a currency conversion function “CURRENCY_CONVERT” built into its formula builder that takes four parameters as input (amount, source currency unit, target currency unit, exchange rate), and outputs an amount of target currency. Using this function, the basic formula for production costs becomes, for example: Production Costs=Σ(IF (Currency of Raw Material x<>‘USD’, CURRENCY_CONVERT (Costs of Raw Material x, Currency of Raw material x, ‘USD’, Some Exchange Rate’), Costs of Raw Material x)+Σ(IF (Currency of Activity x<>‘USD’, CURRENCY_CONVERT(Costs of Activity x, Currency of Activity x, ‘USD’, Some Exchange Rate’), Costs of Activity x).
Entering this complicated, expanded, production costs formula into an application program is both cumbersome and error prone for a user. There are other problems as well. For example, a user who is unaware that the raw material and activity costs values are in different currencies will not include currency conversions when defining and entering the production costs formula, and the formula will produce an incorrect output, unknown to the user. As a further example, consider a business that switches from purchasing raw materials from a domestic supplier that charges in the local currency to purchasing raw materials from a foreign supplier that bills in a foreign currency. There is a large possibility that the business's personnel will forget to modify all the formulas in existing application programs so that they perform the newly needed currency unit conversions. And should they remember, it is costly to modify and test all the formulas in the business's existing application programs.
Accordingly, it is desirable to provide systems and methods in which a user does not need to explicitly define conversions for the currencies or other units involved when building a formula. It is desirable to automatically covert the values in a formula from one unit to another. It is also desirable to reduce the complexity of the formulas entered by a user and to provide greater flexibility. It is also desirable to automatically recognize errors associated with the dimensions of the operands used in formulas and to prevent the errors from entering the formula. It is also desirable to provide systems and methods in which the formulas do not need to be manually adjusted to compensate for currency unit changes, quantity unit changes, and/or other unit or dimension changes in the operands of the formulas.